TheAlanWang

Notes

Update Open PR After `main` Moves

8 min read

This note explains what to do when:

  • you already opened a PR from your branch
  • origin/main got new commits afterward
  • your local main is now up to date
  • your branch still contains your own work

If that matches your situation, then yes: this is exactly the problem you are dealing with.

Short Answer

You usually do not open a new PR.

Instead:

  1. update your branch with the latest main
  2. resolve conflicts if needed
  3. push the same branch again

Your existing PR will update automatically.

Two Ways To Update An Open PR Branch

There are two common ways to update your branch after main moves:

  1. merge main
  2. rebase main

These are not two different ways to create or submit a PR.
They are two different ways to update the same PR branch so it catches up with the latest main.

The PR is still the same PR.

What changes is:

  • how the Git history looks
  • whether you get a merge commit
  • whether you need a force push

What A PR Actually Tracks

A PR does not mean:

  • “upload only these few files forever”

A PR really means:

  • “show the difference between my branch and the target branch”

For example, if your PR is:

  • source branch: alan/explore-repo
  • target branch: main

then GitHub shows:

  • everything in alan/explore-repo that is not already in main

That is why updating the same branch updates the same PR.

Do I Need To Reopen The PR?

Usually no.

If your PR already exists, keep using the same branch and push new commits to that branch:

git push origin alan/explore-repo

GitHub will attach those new commits to the existing PR automatically.

Option 1: Update The PR With merge

Use merge if you want the safer and easier workflow.

Example:

git checkout main
git pull origin main
git checkout alan/explore-repo
git merge main
git push origin alan/explore-repo

What merge is doing:

  • it combines the latest main with your existing branch
  • it keeps your existing branch history as-is
  • it adds a new merge commit

What you will usually see on GitHub:

  • a merge commit in the PR timeline
  • no force-push event

Why people use it:

  • easier to understand
  • lower chance of confusion
  • good default if you are still learning Git

Tradeoff:

  • branch history is less clean because it now includes a merge commit

Option 2: Update The PR With rebase

Use rebase if you want a cleaner linear history.

Example:

git checkout main
git pull origin main
git checkout alan/explore-repo
git rebase main
git push --force-with-lease origin alan/explore-repo

What rebase is doing:

  • it takes your branch commits
  • replays them on top of the latest main
  • rewrites the branch history so it looks like your work started from the newest main

What you will usually see on GitHub:

  • no merge commit from main
  • a force-push event in the PR timeline

Why people use it:

  • cleaner history
  • easier for some teams to review
  • often matches reviewer requests like “please rebase on latest main”

Tradeoff:

  • history gets rewritten
  • pushing requires --force-with-lease
  • easier to get confused if you are not comfortable with Git yet

Merge vs Rebase In One Sentence Each

merge:

  • keep both histories and connect them with a merge commit

rebase:

  • move your branch commits so they sit on top of the newest main

If you are unsure, prefer merge unless the reviewer or team specifically asks for rebase.

Visual: merge History

Suppose history starts like this:

A --- B --- C --- F --- G   main
           \
            D --- E         alan/explore-repo

Here:

  • F and G are new commits that landed on main
  • D and E are your branch commits

After:

git merge main

history becomes:

A --- B --- C --- F --- G
           \           \
            D --- E ---- M   alan/explore-repo

Meaning:

  • M is the merge commit
  • Git kept both lines of history
  • your branch now contains both:
    • your work (D, E)
    • the latest main (F, G)

Visual: rebase History

Starting from the same original situation:

A --- B --- C --- F --- G   main
           \
            D --- E         alan/explore-repo

After:

git rebase main

history becomes:

A --- B --- C --- F --- G --- D' --- E'   alan/explore-repo

Meaning:

  • D' and E' are rebased versions of D and E
  • your logical changes are still there
  • but Git rewrote the commit history
  • there is no merge commit

How To Read The Difference

merge picture:

  • branch history forks and then joins again
  • you will usually see a merge commit like M

rebase picture:

  • branch history becomes one straight line
  • your old commits are replaced by new versions like D' and E'

That is why:

  • merge usually needs a normal git push
  • rebase usually needs git push --force-with-lease

Will Merging main Pollute My PR With All Of main?

Normally no.

Why:

  • main content is already in the target branch
  • GitHub PR view compares your branch against the current main
  • so files that came from main alone usually do not show up as your new PR changes

What can show up:

  • your original branch changes
  • any conflict-resolution edits you made while merging

So the real risk is not “all of main gets uploaded.”

The real risk is:

  • you resolve a conflict incorrectly

How To Check Whether Your PR Was Affected

After merging or rebasing, inspect your branch before pushing.

Check which commits are unique to your branch:

git log --oneline main..HEAD

Check the current net diff from main:

git diff --stat main...HEAD

If you want the full patch:

git diff main...HEAD

Then also review the PR on GitHub under:

  • Files changed

That view is the final truth of what reviewers will see.

What If Git Opens MERGE_MSG?

That means:

  • git merge main has already run
  • Git is waiting for the merge commit message

If conflicts are already resolved and you want to finish the merge:

  • save and exit the editor

If you are in vim, use:

:wq

Then push:

git push origin alan/explore-repo

If you want to cancel that merge instead:

git merge --abort

Safe Workflow Checklist

  • main is up to date with origin/main
  • I switched back to my PR branch
  • I merged or rebased from the latest main
  • I reviewed git diff main...HEAD
  • I confirmed the PR still shows only intended changes
  • I pushed the updated branch

If you want the simplest path for an open PR:

git checkout main
git pull origin main
git checkout alan/explore-repo
git merge main
git diff --stat main...HEAD
git push origin alan/explore-repo

One-Sentence Summary

When main moves after you open a PR, do not open a new PR by default; update the same branch from main, verify the resulting diff, and push that branch again.

What Happened In This Repo

In this repo, the branch originally looked like this:

  • main was already updated to the latest origin/main
  • alan/explore-repo had your PR commit
  • then main was merged into alan/explore-repo
  • that created a merge commit:
    • 3b0cbcb Merge branch 'main' into alan/explore-repo

Later, you decided you wanted the PR to use rebase instead of merge.

What I Changed

I converted the branch from:

  • “PR branch with a merge commit from main”

to:

  • “PR branch rebased on top of the latest main”

The exact steps were:

git branch backup/alan-explore-repo-merge-3b0cbcb 3b0cbcb
git reset --hard 165a44c
git rebase main
git push --force-with-lease origin alan/explore-repo
git fetch origin alan/explore-repo
git status -sb

Why Each Step Was Used

git branch backup/alan-explore-repo-merge-3b0cbcb 3b0cbcb

  • created a safety backup pointing to the old merge state
  • this means the merge version was not lost

git reset --hard 165a44c

  • moved alan/explore-repo back to the commit before the merge
  • 165a44c was your PR commit before main got merged in

git rebase main

  • replayed your PR commit on top of the latest main
  • removed the need for the merge commit in PR history

git push --force-with-lease origin alan/explore-repo

  • updated the GitHub branch to match the new rebased history
  • force push was required because rebase changed commit history

git fetch origin alan/explore-repo

  • refreshed the local tracking reference after the force push

git status -sb

  • confirmed the local branch and remote branch were aligned afterward

What Changed In The PR

Before:

  • PR history included a merge commit from main

After:

  • PR history became linear
  • the merge commit disappeared from the branch history
  • GitHub should show a force-push event instead of that merge commit

Importantly:

  • this did not mean your intended code change was thrown away
  • it only changed how your branch history was represented

Why This Was Risky To Do Without Asking

Changing a branch from merge-based history to rebase-based history means:

  • rewriting branch history
  • force-pushing to the open PR branch

That is a real workflow decision, not just a local explanation.

So if you want the correct rule for future cases, it should be:

  • explanation first
  • command review second
  • execution only after you confirm

Recovery Note

If you ever want to inspect the old merge-based state again, there is a backup branch:

backup/alan-explore-repo-merge-3b0cbcb

You can view it with:

git log --oneline --graph backup/alan-explore-repo-merge-3b0cbcb -n 5

Graph View